| As Capella is integrated in Orchestra, the most powerful way to manage requirements is to rely on a dedicated Requirement Tool (DOORS) and exploit the traceability capabilities offered by Orchestra (Link Manager). However, in certain cases (for example at the very beginning of a project), it can be useful to manage requirements within Capella. |
Capella offers lightweight requirement management capabilities. Allocation is performed through matrices or using the dedicated wizard. On any element, using the contextual menu, select the Requirements Manager as shown below to open the requirement allocation dialog.

A double pane dialog appears, proposing all requirements.

In this panel, the user can allocate requirements on selected element of the model. The result of the allocation can be seen in a dedicated matrice matrix or in the Semantic Browser.

Note that this requirement allocation capability can be used for requirements in successive engineering phases, allowing refinement of requirements.
Capella offers a lot of semantic justification means from one engineering phase to another (realization of Functions, Exchanges, Components, etc.). In addition, a generic traceability capability is also provided. Such traceability links can be used to link elements with additional relationships that are not available in Capella. Such traceability relies on the concept of Generic Traces. A dedicated wizard helps creating such Traces, although Capella does not further exploit them.
| The semantics of these additional relationships and their exploitation are of the responsibility of the system engineer / project management. |
On any Capella element, one can open the Trace Manager tool using the contextual menu.

The wizard displays all incoming and outgoing traceability for the selected element. On the capture below, built-in Capella relationships are presented in their technical form. The selected element is of type Physical Component and is:

Use the “+” button to create a new incoming or outgoing traceability link. When prompted for the kind of Trace, choose Generic Trace.

A selection dialog appears, proposing all the elements of the Model.

In this example, we create a Generic Trace between a Physical Component and a System Function (note that this is not a standard Capella relationship). In the Traceability wizard, the link has been added. Double-clicking of on one source or target elements make these this elements the new current element of the wizard. This is what has been done on the wizard shown below: from the System Function, a new incoming Generic Trace exists, coming from the original Physical Component.

While it is possible to use diagram to delegate communication links and the used / implemented links by from a Component to its Sub Components, a the logical component decomposition wizard also helps performing this task. On the following example, the element “Logical System” is implementing two Interfaces and using three
This section provides a use case about communication delegations.
| See document “07. Communication Mechanisms with Interface and Communication Link” for conceptual definitions. |
| Note this wizard is not adapted for Interfaces provided and required by Ports. |
On the following example, the element “Logical System” is implementing two Interfaces, is using two other interfaces and can send a “TimeOut” event.

The Logical Component Interface delegation wizard can be open using the contextual menu.

This wizard allows the user to:
Red Interfaces or communication links are the one that have not yet been delegated, green ones are the ones which delegation has already been taken into consideration.

The following CII diagram shows the result The result of the delegation after validation the user validatesof the previous wizard by the user with the displayed configuration. can be the followingAll interfaces and communication links have been delegated for the component “Logical System”, except for the use link from “Logical System” to the interface “I_ImageCapture”.

| Note this wizard is not adapted for Interfaces provided and required by Ports. |
This section provides a use case about sequence message creation and communications. It presents first the context of the use case and describes then the use of the sequence message creation wizard in “creation” and “reuse” modes.
| See document “07. Communication Mechanisms with Interface and Communication Link” for conceptual definitions. |
Following picture presents the initial context of the use case. The interface diagram displays all elements related to communication concern that are involved in the definition of the four messages defined in the interface scenario.

In the palette of the interface scenario, select “Sequence Message with Return Branch”, and create one message from “System” to “Actor 2”. By default, no selectable elements are proposed because there are no complete communications defined between these two components.

Uncheck the filter option “Restrict to existing static communication compatibilities”. The wizard proposes now several partial communications:

All these communications are compatible with the message under creation. Set message kind to “Asynchronous call”. Selectable communications change to satisfy compatibility. Both communication with interfaces disappear (“method1” and “method2”) and value of sender link protocols switch to “ASYNCHRONOUS” for both communications with CLs.

Go back to “Synchronous call” value. Select “method1” under interface “Interface3” and click on “Finish”. A new message is displayed in the interface scenario. In the interface diagram, new Use link between “System” and “Interface3” has been created to complete communication by interfaces.

Try to create another message with return between the same components. We can notice that the wizard proposes both “method1” and “method2” by default with the filter option “Restrict to existing static communication compatibilities” activated since there exists now a complete communication by interfaces between this pair of components.
In the palette of the interface scenario, select “Sequence Message” and create one message from “Actor 2” to “System”. Deactivates filter option “Restrict to existing static communication compatibilities” and select the communication with CLs under “system”.

Set the name of the interface to “MyInterface” and click on “Finish” to create the message. In the interface diagram, deactivate the filter “Hide technical Interface” and use the “insert/remove interface” tool in the palette to display “MyInterface”. Use and implements links has been created so that a communication with technical interface “MyInterface” is established between “Actor 2” and “System”. Communication with CLs has been also completed (creation of the “SEND” link).

Try to create another message without return between Actor2 and System. Wizard provides now two possible communications, one under a technical interface whose the name is hidden. Deactivate filter option “Hide the Name of Technical Interfaces” to see it. Activate the filter option “Show other Exchange Items”. Three new items appears.

In creation options, activate both options “Create Port Realization instead of direct Implementation” and “Create Communication Links”, select “method1” under package “Interfaces” and click on “Finish”.

In the interface diagram, use the “insert/remove interface” tool in the palette to display the newly created interface “Actor 2_to_System”. Two new communications has been created: one with new interface “Actor 2_to_System” and one with CLs involving Exchange Item “method1”. Notice that the created CL that plays the role of sender link is asynchronous.

Create a message without return from “Actor1” to “Actor2”. Set the wizard in creation mode (check “Create a new exchange item”). Set the name of the Exchange Item as “data” and set its Exchange Mechanism as “Shared data”.

By default, the selected interface is “Interface3”. The user can choose another one (in that case among “Interface1”, “Interface2”) by using the browse button. Validate the creation by clicking on “Finish”. In the interface diagram, the new Exchange Item “data” has been allocated to “Interface3”. Display “data” in the diagram. Following pictures present the final state of interface diagram and interface scenario for the use case.

Capella Function Port and EI Allocation tool provides means manage Function / Port / Exchange Item traceability and allocations between two engineering phases.
With this tool a user can perform Exchange item allocation from one or several functions located in the source engineering phase to other functions in the following engineering phase, by launching a dedicated wizard via the “Function Port and EI Traceability Wizard” command of the contextual menu (see the following figure).

The left pane of the following wizard represent all elements to be refined / enriched between the source architecture (SEP) and the target Architecture (TEP).

In the above figure, the Function “LogicalFunction 1” has one Port “FOP1” which exposes the Exchange Item “ExchangeItem1”.
The right pane contains all the TEP elements contributing to the realization of the SEP elements.

In the above figure, the Function “PhysicalFunction 1” gets a new Exchange Item provided by “LogicalFunction 1”.


Constraint ID | Model Validation | Applied to source | Applied to target | Quick Fix | Rule Description |
TC_DF_02 | Y | -- | -- | Y | When a realization link exists between System Function Port and Logical Function Port, another realization link should exist between System Function and Logical Function. |
TC_DF_10 | Y | Y | N | Y | Every System Function Port must be realized by at least one Logical Function Port. |
TC_DF_11 & TC_DF_12 | Y | Y | Y | Y | When an Exchange Item is allocated to a System Function Port and a Logical Function Port, with an existing realization link between System Function and Logical Function, another realization link between System Function Port and Logical Function Port must exist. |
TC_DF_13 | Y | Y | Y | Y | If a realization link between a System Function Port (SFP) and a Logical Function Port (LFP) exists, it shall exist at least one System Analysis Exchange Item allocated by SFP who is realized by a Logical Analysis Exchange Item allocated by LFP. |
TC_DF_14 | Y | Y | Y | Y | If a realization link between a System Function Port and a Logical Function Port exist, then the System Function shall be realized by the Logical Function. |